The programmable speaker There has always been some talk around the office about a music box that can be used to make simple sounds, you could even connect it to the circuit network and make simple songs. I put it on my long list of circuit network ideas, and in the past few week it has been coming to life. So today I'll be talking about an exciting new entity coming in 0.15: the Programmable Speaker. It was designed to do two main things: Show configurable GUI alerts and play audio alerts based on circuit conditions. Play audio samples as controlled by the circuit network in a way that simple songs can be created. The entity graphics are placeholder programmer graphics. Let's start with the useful part, it's pretty straightforward. You set your circuit condition, set the sound you want it to make, set whether the sound should be heard in that part of the factory or across the entire map and add an optional GUI alert message. When the circuit condition is true, the speaker will play the selected sound and show the optional GUI alert. You can let the sound play continuously or use simple combinator logic to make the sound at custom intervals. And now that fun part. We knew we wanted the Programmable Speaker to be able to make simple songs. Crazy ideas started to pour in, and it was quickly becoming a full-blown music production DAW with custom synthesizers and control over everything. But this has to be easily controlled by the circuit network without having to build real-time computers with combinators. So in the end I made the Programmable Speaker work as a step sequencer. If you send a circuit network signal pulse, an audio sample will start playing, otherwise nothing will happen. There is no control over the sample length or any special effects, but this means it is quite easy to control it using the circuit network. Enough talk. Here is a demo of a song made using the samples already included. Everything you hear is created inside Factorio. I will leave it to you to analyze the video and figure out how the song is generated. Modders can easily add more audio samples to the entity, including custom alerts. I imagine there will be a voice pack mod that could be programmed using combinators to speak things like "Crude oil is low". I'm sure the Programmable Speaker will be part of some very interesting posts on the Factorio Reddit. There are some other circuit network improvements coming to 0.15, but I will talk more about them in some other FFF. The map download struggle (Technical) For as long as I can remember, our multiplayer map downloader had (among other problems) the problem that it would get stuck at 100%. It was an extremely rare problem some random person would report. We would keep ignoring the bug throwing it in "Pending" or "Duplicates" or "1/0 Magic", but after a few months some other person would report it again. I seem to have a habit of obsessing over these rare "unfixable" bugs (audio mixer crashing, vsync performance issues, non-pixel-perfect sprite drawing), so I started looking into this map downloader issue. First I was looking at the map downloader code itself, thinking surely there is something wrong there. This was a long process because I had no way of reproducing the issue, so it usually involved going back and forth with a person who was experiencing the issue. I would create an executable that would create detailed logs, that person would run the game using that, I would investigate the logs and see that our map downloader works correctly. The I would add more logging and so on. By the time I would reach some kind of conclusion that person would stop answering and probably stop playing Factorio. But near the end thanks to some helpful players, I was able to see what was happening. Looking at the wireshark capture for both the client and the server, it seems that a packet with a specific content or a specific checksum always gets filtered. Some cheeky firewall from the computer, router or ISP is looking inside the packet data and blocking the packets it does not like. No matter how many times I resend that packet, it never gets through, while all the other hundreds of thousands of game and map packets have no problem getting through. Correct me if I'm wrong, but something like this should not be happening. You can read all the details and see the packet data last posts of the forum topic. The issue seems to be resolved if I add one byte of random data to the packet, but I would like to know why is this happening in the first place. If you know what is happening or you know someone that might, please don't hesitate to enlighten us :) This shows how hard it is to make software that "just works" for everyone. There will always be that 0.1% of people who end up having problems that no one could have ever foreseen. Big thanks to admalledd, dadymax, Rippie and the other forum members who helped or are still helping me investigate this odd issue. In other good news, while Rseding91 was also looking at the map download code trying to investigate this problem, he found we had some slow code doing hard drive seeking, slowing down map uploads. He improved it and you should see better map transfer speeds on LAN and high speed connections. As usual, let us know what you think at the forums.
Hello, a wave of illness has afflicted the team these last few weeks, but things are starting to pick up again. With the collective health of the office back to normal, progress is advancing well on the features for 0.15.
Alpha blending and pre-multiplied alpha From time to time there is some confusion inside the team about how sprites are blended with the background when rendering, and what kind of effects we are able to achieve by tinting the sprites. So I (Posila) have decided to write up a few paragraphs about how alpha blending works (not only in Factorio), and what it means when someone talks about pre-multiplied alpha. When the GPU is figuring out what color it should draw on a particular pixel position, it runs a blending operation on just the computed pixel color and original color in the render target. There are several common blending operation modes (additive, multiplicative, overwrite, etc.), but the most common one used in Factorio is alpha blending. It calculates the resulting color using following equation (usually the new color is called 'source' and the background color that is being overwritten is called 'destination'): You can easily see that a source with alpha 0 will be fully transparent and the one with alpha 1 will be fully opaque. In games it is common to use a pre-multiplied alpha, which means the color channels of textures are stored in memory being already pre-multiplied by the alpha channel. Alpha blending with pre-multiplied alpha uses a simplified equation: Besides a slight performance gain from the GPU not having to do bunch of multiplication all the time, this equation allow us to do some extra effects we couldn't do without pre-multiplied alpha. Factorio renders sprites as colored polygons with texture. We usually refer to the color of a polygon as the 'tint', and every pixel of a sprite is multiplied with its tint. This is useful mainly for color masks, for example the diesel locomotive has a grayscale color mask which is tinted by the color it has set. Tints should have a pre-multiplied alpha too, but they don't have to, so we can use it to lie about the colors and alpha to the GPU. For example if we use tint {r=1,g=1,b=1,a=0} we can simplify previous equation even further and we get additive blending: This is great because that means we can switch between alpha and additive blending without having to change the blending state in graphics API, which would break sprite batching and result in an increase in the CPU cost of rendering. For some effects we use a tint with alpha between 0 and 1 heavily. This makes the result appear to be a combination of additive and alpha blending. For example, fire would eventually blend into a single solid color with pure additive blending, or would not look like it is emitting light with pure alpha blending. By using tint (1, 1, 1, 0.35) on the flame sprites, the brightness of overlapping flames adds up partially, but the flames don't completely lose their details. The same trick is used for smoke. Textures with pre-multiplied alpha also produce better results in texture filtering , which is probably the main reason why they are so widely used in the videogame industry.
Hello, It has been very quiet in the office this week, the calm twilight between Christmas and the New year.
Hello. With Christmas nearly upon us, life in the office has slowed down nearly to the point of complete hibernation. But we still bring you your scheduled programme to give you something to look forward to in the next year. For the past few weeks, I've been working on our shiny new blueprint library. We already introduced the library in FFF 161, but to briefly recapitulate: The blueprint library is a place for you to keep your blueprints, and it does two things for you: Blueprints that you save in your library are saved on your computer, and when you load a new save, those blueprints are still available in your library. In multiplayer games players can see each others blueprints and can exchange them easily.
Combat Balance Twinsen here. As you might have read in Friday Facts #166, we wanted to do some combat balancing. First, to not bring the hopes of everyone up too much, this did not mean a combat overhaul. It means mostly tweaking numbers to make the game more fun and make some of the the weapons more viable. No new entities or new mechanics. As I was doing the combat balance, it was clear the everyone has their own different opinion of how combat is, how it should be and how to make it "better". It's hard to please everyone, especially when you are just tweaking numbers. To try to objectively evaluate combat I used the following methodology. As the game progresses, the player's power increases through research, but so do the biters(mainly due to evolution factor). So I split the game in 7 sections based on research progress. Each section also has the evolution factor I tested biters will approximately have in an average game. Initial - 0 evolution Red - 0.1 evolution Red+Green - 0.3 evolution Red+Green+Military - 0.4 evolution Red+Green+Blue+Military - 0.7 evolution Red+Green+Blue+Military+High Tech - 0.9 evolution Red+Green+Blue+Military+High Tech+Production - 0.99 evolution Then for each section I tested both offensive combat and defensive combat using the available guns and turrets and tweaked the numbers accordingly. While tweaking the numbers, I keep this in mind (this is not a complete list): Fun always wins: I prefer changes that are more fun and less annoying even if it means it could be slightly unbalanced. New weapons should be slightly more powerful than old weapons, to incentivize you to experiment. So near the end game, a rocket launcher will be better than the machine gun. Destroying biter bases is hard in the beginning and significantly easier toward the end game, to give the sense of combat power progression. Defending is not too hard in the beginning. I try not to put a new player in the situation of "you didn't prepare properly, you have to start a new game, because no matter what you do you will get killed". Then throughout the game you have to upgrade your defenses as the biters evolve. So far, the changelog looks like this. There are many numbers that were tweaked and are not included in this list. Player regains health at a much higher rate, but only after being out of combat for 10 seconds. Discharge defense equipment pushes back, stuns and damages nearby enemies when activated by the remote. Decreased the size of Discharge defense equipment from 3x3 to 2x2. Greatly increased the damage of Personal Laser Defense Equipment. Flamthrower gun has a minimum range of 3. The flames created on ground from the flamethrower significantly increase in duration and damage when more fuel is added to them by firing at the same spot. Increased fire resistance of biter bases. Increased the health of player non-combat buildings. Increased player health from 100 to 250. Increased collected amount and effectiveness of Raw Fish. Increased the damage, range and health of biters worms. Decreased health and resistance of Behemoth biters. Doubled the stack size of all ammos. Tweaked the cost and crafting time of some ammos. Increased the damage of most player ammos. Greatly increased the damage and fire rate of Rockets and Cannon Shells. Increased the collision box of Cannon Shells. Increased Tank health and resistances. Added research for Tank Cannon Shells damage and shooting speed. Tweaked research bonuses and added more end-game research for military upgrades. Greatly increased the damage of Mines. They also stun nearby enemies when they explode. Biters stop following player after 10 sec of not giving or receiving damage if the player is more than 50 tiles away. Other minor changes. As usual, these changes are not final and will probably change to some degree as we playtest more. There are still many things to be done. We are always talking about more end-game weapons, so don't worry, the combat in the late-game will be even more worry-free. There is also one thing that we always talked about trying to remove: turret-creep (destroying biters base building turrets closer and closer). This method is very powerful and usually doesn't cost anything. So far I believe that we did not find a simple, fun and fair solution. Ideas include: large power-up times(annoying and also weakens base defense); simply not allowing turrets to be build near biter bases (makes the player feel cheated); underground anti-turret worms (sugar-coated version of the previous idea). With the combat changes that were done I believe there is almost always an option to destroy bases without being forced to use turret-creep.In the end maybe your ingenuity and effort of building all those electric poles should be rewarded; If the player wants to do it that way, why not let him? Let us know what you think.
Nightvision nightmare As Twinsen continues tweaking the combat, he started to complain about the “green fog” effect that is applied during night when the player’s character has nightvision goggles equipped. Nightvison in 0.14 works in a way that it reduces the darkness of night, and then draws a transparent green overlay. This washes out the colors, reduces contrast, and makes the picture pretty unpleasant to look at. The first idea was to just make the green overlay be rendered around light sources, to reward players who put lights into their bases, by not making the base look worse with nightvision on. This didn’t look too good, and as we were trying to figure out how to improve it, other developers, especially artists, caught on to what we were doing, and started to provide their own ideas. Next we tried to darken only the red and blue channels when nightvision is on. This will make the picture green without losing contrast and we can drop the green overlay. We kept “not applying effect onto lighted area” logic and it started to look interesting. Albert wasn’t happy with the result though, so we continued experimenting. We added a soft green tint to lighted areas, and a bright green glow onto the transition between light and darkness. Then we added white highlights to light sources and it finally started to pleasant to look at. We will stick with this version for time being, but plan to work on it more. We can’t agree if this change is for better or worse even inside the team. It seems everybody has their own idea about how nightvision effect should look like and what benefits it should provide to players. For example it would be nice to have goggles with greyscale effect that would highlight biters. So maybe heat vision?
Hello, Denis has joined us for another month here in the office, a small overlap with Rseding who is flying back to the USA next week. With the festive season upon us, Tomas and Kovarex have both taken some time off for a vacation.
Hello,the hopefully final 0.14 version was recently released, meanwhile most of the team have been assigned their major tasks for 0.15.
